The present disclosure relates generally to more efficient signaling and more specifically to a system and apparatus for reducing an amount of information communicated using a first signaling protocol (e.g., session initiation protocol (SIP) signaling) or a second signaling protocol (e.g., I1 interface signaling).
As used herein, the terms “User Agent” and “UA” can refer to wireless devices such as mobile telephones, personal digital assistants (PDAs), handheld or laptop computers, and similar devices or other user equipment (“UE”) that have telecommunications capabilities. In some embodiments, a UA may refer to a mobile, wireless device. The term “UA” may also refer to devices that have similar capabilities but that are not generally transportable, such as desktop computers, set-top boxes, or network nodes. Throughout this disclosure, UA may refer to a SIP UA such as a wireless device, set-top box, or other communication devices and is interchangeable with the term UA.
In Third Generation Partnership Project (3GPP) systems, an internet protocol (IP) multimedia subsystem (IMS) allows for the delivery of IP multimedia services. Using IMS, a UA may transmit and receive multimedia and/or voice packet switched (PS) communications via a base station implementing one or more IMS Functional Components. To implement IMS, networks rely upon session initiation protocol (SIP) to provide a text-based signaling protocol that may be used to communicate between a UA and the IMS Core Network (CN), between the IMS CN and Application Servers, and between various other components of the IMS Network.
In existing networks, IMS centralized services (ICS) allow various IMS services to be provided to a UA using a wireless network where voice communications are provided over a circuit-switched (CS) bearer and other media components are provided over packet-switched (PS) bearers and the control of the signaling may be performed using IMS or another protocol called I1 that is being defined in 3GPP TS 24.294. Example networks may include long term evolution (LTE) networks, Global System for Mobile communication (GSM) Enhanced Data rates for GSM Evolution (EDGE) Radio Access Network (GERAN) networks, or Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN) networks. ICS may also be configured to provide service control for features in the IMS network in circumstances when the wireless device is connected to a non-IMS network, such as when the UA is connected to a mobile switching center (MSC). The features controlled by ICS may include call hold, call transfer, calling line identity, etc.
Generally, ICS requires the simultaneous support of a bearer for voice and a bearer to support the control signaling that uses SIP signaling. In some circumstances, however, the bearer for supporting SIP signaling may be unavailable, for example, because Gm connectivity does not exist (e.g., no PS roaming agreement or IMS roaming agreement exists), the UA is unable to register with the IMS infrastructure because of operational issues, or dual transfer mode (DTM) is unavailable in the cell or the wireless device. In that case, the I1 protocol as being defined in 3GPP TS 24.294 allows a wireless device to implement a signaling protocol using a CS bearer in the place of the Gm interface. The signaling protocol can be a SIP-like protocol. In that case, the I1 protocol uses or binds to or is wrapped in transport protocols such as, but not limited to, short message service (SMS) or unstructured supplementary service data (USSD), etc. The use of these transport protocols limits the information payload per message or signaling, generally, to a maximum of 160 octets. Unfortunately, SIP is a verbose character-based protocol and, as a result, SIP-encoded signaling messages often do not fit in a limited payload such as that provided by SMS or USSD. Table 1 illustrates an example SIP-encoded message.
TABLE 1INVITE tel:+1-212-555-6666 SIP/2.0Via: SIP/2.0/UDP msc2.home1.net;branch=z9hG4bKnashds7Max-Forwards: 70Route: <sip:icscf1.home1.net:lr>P-Preferred-Identity:<sip:user2_public1@home1.net>,<tel:+1-212-555-2222>P-Charging-Vector:icid-value=“AyretyU0dm+6O2IrT5tAFrbHLso=023551024”; orig-ioi=home2.netAccept-Contact:*;+g.3gpp.icsi-ref=“urn%3Aurn-7%3gpp-service.ims.icsi.mmtel”P-Access-Network-Info:3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11Privacy: noneFrom: <sip:user2_public1@home1.net>;tag=171828To: <tel:+1-212-555-6666>Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6Cseq: 127 INVITESupported: 100rel, precondition, gruu, 199Contact:  <sip:user2_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;   +g.3gpp.icsi-ref=“urn%3Aurn-7%3gpp-service.ims.icsi.mmtel”;+g.3gpp.ics=“server”Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFERContent-Type: application/sdpContent-Length: (...)v=0o=− 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eees=c=IN IP6 5555::aaa:bbb:ccc:eeet=0 0m=audio 3456 RTP/AVP 97 96b=AS:25.4a=curr:qos local sendrecva=curr:qos remote nonea=des:qos mandatory local sendrecva=des:qos none remote sendrecva=rtpmap:97 AMRa=fmtp:97 mode-set=0,2,5,7; mode-change-period=2a=rtpmap:96 telephone-eventa=maxptime:20
With reference to Table 1, there are several data elements that are included within the SIP message that add to the message's verbosity. For example, the original party identity (“P-Preferred-Identity: <sip:user2_public1@home1.net>,<tel:+1-212-555-2222>”) may include a SIP uniform resource identifier (URI) and a tel URI. The Public User Identity SIP and tel URI strings (which can also be transported in SIP messages in other SIP header fields than the P-Preferred-Identity header field), however, can be relatively verbose as they take the form of “user@domain.” Even though they are verbose, it is important to designate a Public User Identity of the user within a SIP message as a user may have many identities (e.g., Work, Home, or private identities) that are all registered with a particular wireless device. Accordingly, when transmitting a SIP message, the wireless device must determine which Public User Identity to use for identification and include that information in the SIP message. Similarly, when a UA receives a call (e.g., a wireless device terminated session) the user is made aware of which identity they were called on, so they know how to answer the call. Accordingly, the user identity information is included in SIP messages sent to and received from a UA.
Various SIP UA capabilities may also be included in the SIP message (e.g., “Accept-Contact: *;+g.3gpp.icsi-ref=“urn%3Aurn-7%3gpp-service.ims.icsi.mmtel”). The SIP UA capabilities provide the network with an indication of the wireless device's capabilities. Because a wireless device may support many services, the SIP UA capabilities portion of the SIP message may include a significant amount of data necessary for a network to effectively communicate with a UA. The SIP message may also include a Call-ID header field (e.g., “Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6”) that may be used to refer to an existing SIP session using a Target-Dialog, such as in the case of an I1 message adding a voice component over a CS bearer.
Accordingly, SIP messages may include several data elements that include verbose data values such as definitions of public identities, device capabilities, and existing SIP session identifiers. In systems implementing SIP-like protocols over I1 interfaces, although these data points may be removed, it is generally preferable that they be included to provide an easier interworking and mapping between I1 and, for example, SIP. Unfortunately, these verbose data points may generate I1 messages that are larger than the maximum payload of the I1 interface resulting in inefficient transmission. Accordingly, there exists a need for compressing or otherwise minimizing the size of SIP-like messages over I1-like interfaces.